Selectively presenting timestamped time-series data values for retrieved supervisory control and manufacturing/production parameters

ABSTRACT

A process control and manufacturing information database client application is disclosed for rendering and displaying a filtered set of received time-series data. A client application, such as a trending client that graphically displays a series of data point values for a particular observed parameter of a manufacturing process receives, via a data acquisition interface, a set of timestamped time-series data values for an observed parameter from a process control and manufacturing information database. Thereafter, the client application invokes a time-series data filter that includes/supports at least one filtering operation that is applied to the set of timestamped time-series data values to render a filtered data set for plotting/drawing on the graphical display interface. The filtered data set is thereafter rendered by a display function as a series of plotted points on a time-line graph.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application generally relates to Jensen et al. U.S.application Ser. No. 11/190,179 filed on Jul. 26, 2005, entitled “SYSTEMAND METHOD FOR RETRIEVING INFORMATION FROM A SUPERVISORY CONTROLMANUFACTURING/PRODUCTION DATABASE,” and Avergun et al. U.S. applicationSer. No. 11/189,353 filed on Jul. 26, 2005, entitled “SYSTEM AND METHODFOR APPLYING DEADBAND FILTERING TO TIME SERIES DATA STREAMS TO BE STOREDWITHIN AN INDUSTRIAL PROCESS MANUFACTURING/PRODUCTION DATABASE.” Thecontents of each of the above identified applications are expresslyincorporated herein by reference in their entirety including thecontents and teachings of any references contained therein.

TECHNICAL FIELD

The present invention generally relates to computing and networked datastorage systems, and, more particularly, to techniques for managing(e.g., storing, retrieving, processing, etc.) streams of supervisorycontrol, manufacturing, and production information. Such information istypically rendered and stored in the context of supervising automatedprocesses and/or equipment. The data is thereafter accessed by a varietyof database clients such as, for example, by trending applications.

BACKGROUND

Industry increasingly depends upon highly automated data acquisition andcontrol systems to ensure that industrial processes are run efficientlyand reliably while lowering their overall production costs. Dataacquisition begins when a number of sensors measure aspects of anindustrial process and report their measurements back to a datacollection and control system. Such measurements come in a wide varietyof forms. By way of example the measurements produced by asensor/recorder include: a temperature, a pressure, a pH, a mass/volumeflow of material, a counter of items passing through aparticular-machine/process, a tallied inventory of packages waiting in ashipping line, cycle completions, etc. Often sophisticated processmanagement and control software examines the incoming data associatedwith an industrial process, produces status reports and operationsummaries, and, in many cases, responds to events/operator instructionsby sending commands to actuators/controllers that modify operation of atleast a portion of the industrial process. The data produced by thesensors also allow an operator to perform a number of supervisory tasksincluding: tailor the process (e.g., specify new set points) in responseto varying external conditions (including costs of raw materials),detect an inefficient/non-optimal operating condition and/or impendingequipment failure, and take remedial action such as move equipment intoand out of service as required.

A very simple and familiar example of a data acquisition and controlsystem is a thermostat-controlled home heating/air conditioning system.A thermometer measures a current temperature, the measurement iscompared with a desired temperature range, and, if necessary, commandsare sent to a furnace or cooling unit to achieve a desired temperature.Furthermore, a user can program/manually set the controller to haveparticular setpoint temperatures at certain time intervals of the day.

Typical industrial processes are substantially more complex than theabove-described simple thermostat example. In fact, it is not unheard ofto have thousands or even tens of thousands of sensors and controlelements (e.g., valve actuators) monitoring/controlling all aspects of amulti-stage process within an industrial plant or monitoring units ofoutput produced by a manufacturing operation. The amount of data sentfor each measurement and the frequency of the measurements varies fromsensor to sensor in a system. For accuracy and to facilitate quicknotice/response of plant events/upset conditions, some of these sensorsupdate/transmit their measurements several times every second. Whenmultiplied by thousands of sensors/control elements, the volume of datagenerated by a plant's supervisory process control and plant informationsystem can be very large.

Specialized process control and manufacturing/production informationdata storage facilities (also referred to as plant historians) have beendeveloped to handle the potentially massive amounts time-series ofprocess/production information generated by the aforementioned systems.An example of such system is the WONDERWARE IndustrialSQL Serverhistorian. A data acquisition service associated with the historiancollects time-series data values for observed parameters from a varietyof data sources (e.g., data access servers). The collected time-seriesdata is thereafter deposited with the historian to achieve data accessefficiency and querying benefits/capabilities of the historian'srelational database. Through its relational database, the historianintegrates plant data with event, summary, production and configurationinformation.

Traditionally, plant databases, referred to as historians, havecollected and stored in an organized manner (i.e., “tabled”), tofacilitate efficient retrieval by a database server, streams oftimestamped time-series data values for observed parameters representingprocess/plant/production status over the course of time. The status datais of value for purposes of maintaining a record of plant performanceand presenting/recreating the state of a process or plant equipment at aparticular point in time. Over the course of time, even in relativelysimple systems, Terabytes of the steaming time stamped information aregenerated by the system and tabled by the historian.

Information is retrieved from the tables of historians and displayed bya variety of historian database client applications including trendingand analysis applications at a supervisory level of an industrialprocess control system/enterprise. Such applications include graphicaldisplays for presenting/recreating the state of an industrial process orplant equipment at any particular point (or series of points) in time. Aspecific example of such client application is the WONDERWAREActiveFactory trending and analysis application. This trending andanalysis application provides a flexible set of graphical display andanalytical tools for accessing, visualizing and analyzing plantperformance/status information provided in the form of streams oftime-series data values for observed parameters.

In presenting time-series data from industrial operations and/orcontrolled systems, the amount of raw data generated for observedparameters can number in the millions of stored values.Displaying/plotting the values on trending graphical displays consumesconsiderable computer resources.

SUMMARY OF THE INVENTION

In accordance with the present invention, a client application invokes afiltering operation upon received time-series data point sets. Theclient application thereafter plots/draws the filtered data point setson a graphical display.

In the exemplary embodiments disclosed herein, a process control andmanufacturing information database client application, such as atrending client that graphically displays a series of data point valuesfor a particular observed parameter of a manufacturing process,initially receives, via a data acquisition interface, a set oftimestamped time-series data values for an observed parameter from aprocess control and manufacturing information database.

Thereafter, the client application invokes a time-series data filter.The time-series data filter includes/supports at least one filteringoperation that is applied to the set of timestamped time-series datavalues to render a filtered data set for plotting/drawing on thegraphical display interface. Furthermore, the exemplary embodimentincorporates an extensible, component-based, architecture that enablessupplementation of the set of filter types supported by the clientapplication. Embodiments also support tuning various characteristics ofthe filters (e.g. time periods, deadband value ranges, etc.).

The filtered data set is thereafter rendered by a display function as aseries of plotted points on a time-line graph. Thus, the clientapplication is able to reduce, in a meaningful manner, the quantity ofdata points plotted on a graphical display representing a set oftime-series data point values.

BRIEF DESCRIPTION OF THE DRAWINGS

While the appended claims set forth the features of the presentinvention with particularity, the invention, together with its objectsand advantages, may be best understood from the following detaileddescription taken in conjunction with the accompanying drawings ofwhich:

FIG. 1 is a schematic diagram of an exemplary networked environmentwherein a process control database client application (e.g., a trendingdisplay program) component embodying the present invention isadvantageously incorporated;

FIG. 2 is a schematic drawing of functional/structural aspects of ahistorian server/service and trending application embodying the presentinvention;

FIG. 3 is a set of data filtering operations supported by (or for) aclient application embodying the present invention;

FIGS. 4 a and 4 b graphically depict stair-step and interpolated dataprocessing;

FIG. 5 depicts an illustrative sequence of data points for the purposeof demonstrating a best fit data compression/filtering/selectionoperation;

FIG. 6 is a flow diagram depicting the general steps performed by thedata compression interface on each received point value when swingingdoor data compression is enabled for a steam of time series data pointvalues;

FIG. 7 illustratively depicts a sequence of received values and theeffect of the data compression method of FIG. 6, including value andrate deadbands with a deadband override period, on designating the setof received data points that will be plotted on a client application'sgraphical display;

FIG. 8 illustratively depicts a sequence of received values and theeffect of the data compression interface, including a rate deadband andreal-time window, on designating the set of received data points fordisplay;

FIG. 9 is a flowchart summarizing a real-time forced storage windowmethod;

FIG. 10 is a flowchart summarizing operation of a value/time filter on aset of received data values;

FIG. 11 is a flowchart summarizing the operation of a client applicationto receive, filter, and then plot a set of time-series data values; and

FIG. 12 is an exemplary graphical user interface for a clientapplication depicting a time sequenced graphical representation of avariable value based upon a series of filtered and plotted values.

DETAILED DESCRIPTION OF THE DRAWINGS

A control system/plant historian service supports retrieval operationswherein previously tabled data is provided on demand and in response toclient requests. The term “tabled” is used herein to describe datareceived by the database/historian server and stored in an organizedmanner to facilitate later retrieval by the database/historian server inresponse to client requests. The terms “client requests” and “on demand”are intended to be broadly defined. A “client request”, unlessspecifically noted, includes requests initiated by human machineinterface users and requests initiated by automated client processes.

Client applications that request and display trending timestamped dataprovided, for example, by the aforementioned historian server over adesignated time span have not adequately addressed presentingtime-series data in instances where the sample rate of the time-seriesdata far exceeds the rate at which the data is best displayed via atrending application's graphical interface. As will be shown by way ofillustrative examples provided herein, a historian client applicationembodying the present invention applies a filter to data retrieved froma database/historian server before plotting the data points on agraphical display. In accordance with illustrative embodiments, anexemplary trending application performs “best fit”, “swinging door”, and“value/time” filtering on retrieved time-series data streams forparameters of interest. Each of the three exemplary filtering techniquesis described herein below.

The following description is based on illustrative embodiments of theinvention and should not be taken as limiting the invention with regardto alternative embodiments that are not explicitly described herein.Those skilled in the art will readily appreciate that the illustrativeexample in FIG. 1 represents a simplified configuration used forillustrative purposes. In particular, the systems within which thepresent invention is incorporated are substantially larger and thebreadth of network connections to client applications greater (includingclients that access the historian via an Internet portal server). Whilethe illustrative network arrangement depicts a local area networkconnection between a historian node and client application nodes, otherclient applications are potentially connected via wide-area networklinks to the historian. In many instances, the number of data sources isseveral times larger—resulting in massive quantities of time-seriesprocess data associated with potentially hundreds and even thousands ofdata points in a process control system.

FIG. 1 schematically depicts an illustrative environment wherein asupervisory process control andmanufacturing/production information datastorage facility (also referred to as a plant historian or historian)100 and historian client applications embodying the present inventionare potentially incorporated. The network environment includes a plantfloor network 101 to which a set of process control and manufacturinginformation data sources 102 are connected either directly or indirectly(via any of a variety of networked devices including concentrators,gateways_(;) integrators, interfaces, etc.).

While FIG. 1 illustratively depicts the data sources 102 as a set ofprogrammable logic controllers (PLCs) 1-N, the data sources 102 compriseany of a wide variety of data sources (and combinations thereof)including, for example, programmable logic controllers (PLCs),input/output modules, and distributed control systems (DCSs). The datasources 102, in turn, are coupled to, communicate with, and control avariety of devices such as plant floor equipment, sensors, andactuators. Data received from the data sources 102 potentiallyrepresents, for example, discrete data such as states, counters, events,etc. and analog process data such as temperatures, tanklevels/pressures, volume flow, etc. A set of I/O servers 104, forexample data access servers developed and provided by WONDERWARE,acquire data from the data sources 102 via the plant floor network 101on behalf of a variety of potential clients/subscribers—including thehistorian 100.

The exemplary network environment includes a production network 110. Inthe illustrative embodiment the production network 110 comprises a setof client application nodes 112 that execute, by way of example,trending applications that receive and graphically display time-seriesvalues for a set of data points. One example of a trending applicationis Wonderware's ACTIVE FACTORY application software. The data drivingthe trending applications on the nodes 112 is acquired, by way ofexample, from the plant historian 100 that also resides on theproduction network 110. Alternatively, the client applications reside onnon-local nodes communicatively connected to the historian 100 via awide area network link. The historian 100 includes database services formaintaining and providing a variety of plant/process/productioninformation including historical plant status, configuration, event, andsummary infounation.

A data acquisition service 116, for example WONDERWARE'S remote IDAS,interposed between the I/O servers 104 and the plant historian 100operates to maintain a continuous, up-to-date, flow of streaming plantdata between the data sources 102 and the historian 100 forplant/production supervisors (both human and automated). The dataacquisition service 116 acquires and integrates data (potentially in avariety of forms associated with various protocols) from a variety ofsources into a plant information database, including timestamped dataentries, incorporated within the historian 100.

The physical connection between the data acquisition service 116 and theI/O servers 104 can take any of a number of forms. For example, the dataacquisition service 116 and the I/O servers can comprise distinct nodeson a same network (e.g., the plant floor network 110). However, inalternative embodiments the I/O servers 104 communicate with the dataacquisition service 116 via a network link that is separate and distinctfrom the plant floor network 101. In an illustrative example, thephysical network links between the I/O servers 104 and the dataacquisition service 116 comprise local area network links (e.g.,Ethernet, etc.) that are generally fast, reliable and stable.

The connection between the data acquisition service 116 and thehistorian 100 can also take any of a variety of fonns. In an embodimentof the present invention, the physical connection comprises aninteimittent/slow connection 118 that is potentially: too slow to handlea burst of data, unavailable, or faulty. The data acquisition service116 and/or the historian therefore include components and logic forhandling streams of time-series data values for observed parameters fromcomponents connected to the plant floor network 101. The time-seriesdata received by the historian 100 are preferably assigned timestamps atthe point of acquisition rather than at the time of reception by thehistorian 100 to ensure the values are properly sequenced. Furthermore,the points of acquisition preferably utilize synchronized clocks (e.g.,GPS clock signal) to ensure that all sources of data accurately assigntimestamps to their data prior to submission to the historian 100 (viathe data acquisition service 116).

Turning to FIG. 2 an exemplary schematic diagram depicts functionalcomponents associated with the historian 100 and a client application,having an associated data acquisition interface for obtainingtime-series data values for observed parameters from the historian 100,on node 112 a. In accordance with an exemplary embodiment, the clientapplication incorporates graphing optimization functionality (describedherein below) to reduce the number of actual plotted data points on theclient application's graphical display. The historian 100 generallyimplements a storage interface 200 comprising a set offunctions/operations for receiving and tabling data from the dataacquisition service 116 via connection 118. The received data is storedin one or more tables 202 maintained by the historian 100.

By way of example, the tables 202 include time-series pieces of datavalues for observed parameters received by the historian 100 via a dataacquisition interface to a process control/production informationnetwork such as the data acquisition service 116 on network 101. In theillustrative embodiment each piece of data is stored in the form of avalue, quality, and timestamp. These three parts to each piece of datastored in the tables 202 of the historian 100 are described brieflyherein below.

Timestamps

The historian 100 tables data received from a variety of “real-time”data sources, including the I/O Servers 104 (via the data acquisitionservice 116). The historian 100 is also capable of accepting “old” datafrom sources such as text files. By way of example, “real-time” data canbe defined to exclude data with timestamps outside of ±30 seconds of acurrent time of a clock maintained by a computer node hosting thehistorian 100. However, data characterizing data is also addressable bya quality descriptor associated with the received data. Properimplementation of timestamps requires synchronization of the clocksutilized by the historian 100 and data sources. In an exemplaryembodiment, all data values are assigned UTC timestamps. However, thisis not essential for carrying out the present invention. The clientapplication need only know, through implicit/explicit designation, thetime zone assigned to the timestamp for a data point value.

Quality

The Historian 100 supports two descriptors of data quality:“QualityDetail” and “Quality.” The Quality descriptor is based primarilyon the quality of the data presented by the data source, while theQualityDetail descriptor is a simple indicator of “good”, “bad” or“doubtful”, derived at retrieval-time. Alternatively, the historian 100supports an OPCQuality descriptor that is intended to be used as a soledata quality indicator that is fully compliant with OPC qualitystandard(s). In the alternative embodiment, the QualityDetail descriptoris utilized as an internal data quality indicator.

Value

A value part of a stored piece of data corresponds to a value of areceived piece of data. In exceptional cases, the value obtained from adata source is translated into a NULL value at the highest retrievallayer to indicate a special event, such as a data source disconnection.This behavior is closely related to quality, and clients typicallyleverage knowledge of the rules governing the translation to indicate alack of data, for example by showing a gap on a trend display.

The following is a brief description of the manner in which thehistorian 100 receives time-series data for observed parameters from areal-time data source and stores the data as a timestamp, quality andvalue combination in one or more of its tables 202. The historian 100receives a data point for a particular tag (named data value) via thestorage interface 200. The historian compares the timestamp on thereceived data to: (1) a current time specified by a clock on the nodethat hosts the historian 100, and (2) a timestamp of a previous datapoint received for the tag. If the timestamp of the received data pointis earlier than, or equal to the current time on the historian nodethen:

If the timestamp on the received data point is later than the timestampof the previous point received for the tag, the received point is tabledwith the timestamp provided by the real-time data source.

If the timestamp on the received data point is earlier than thetimestamp of the previous point received for the tag (i.e. the point isout of sequence), the received point is tabled with the timestamp of thepreviously tabled data point “plus 5 milliseconds”. A specialQualityDetail value is stored with the received point to indicate thatit is out of sequence (the original quality received from the datasource is stored in the “quality” descriptor field for the stored datapoint).

On the other hand, if the timestamp of the point is later than thecurrent time on the historian 100's node (i.e. the point is in thefuture), the point is tabled with a timestamp equal to the current timeof the historian 100's node. Furthermore, a special value is assigned tothe QualityDetail descriptor for the received/tabled point value toindicate that its specified time was in the future (the original qualityreceived from the data source is stored in the “quality” descriptorfield for the stored data point).

The historian 100 can be configured to provide the timestamp forreceived data identified by a particular tag. After proper designation,the historian 100 recognizes that the tag identified by a received datapoint belongs to a set of tags for which the historian 100 supplies atimestamp. Thereafter, the timestamp of the point is replaced by thecurrent time of the historian 100's node. A special QualityDetail valueis stored for the stored point to indicate that it was timestamped bythe historian 100. The original quality received from the data source isstored in the “quality” descriptor field for the stored data point.

It is also noted that in an exemplary embodiment the historian 100supports application of a rate deadband filter to reject new data pointsfor a particular tag where a value associated with the received pointhas not changed sufficiently from a previous stored value for the tag.

Having described a data storage interface for the historian 100,attention is directed to retrieving the stored data from the tables 202of the historian 100. Access, by data acquisition interfaces of clientsof the historian 100, to the stored contents (e.g., time-series datavalues for observed parameters) of the tables 202 is facilitated by aretrieval interface 206. The retrieval interface 206 exposes a set offunctions/operations/methods callable by the data acquisition interfacesof client applications residing on client nodes attached to the network110 (e.g., a trending client application executing on node 112 a), forquerying the contents of the tables 202.

In response to receiving a query message, the retrieval interface 206supplies timestamped series data to the requesting client application.In an exemplary embodiment, the timestamps for the data provided via theretrieval interface 206 of the historian are based upon any time zonestandard specified by the client application (e.g., UTC). The clientapplications, by way of example, request and store time-series datavalues from the retrieval interface 206 of the historian 100 accordingto a single time zone standard (e.g., UTC). Alternatively, the clientapplications convert the timestamps of received time-series data valuesto the single time zone standard upon receipt from the historian 100.Furthermore, in accordance with exemplary embodiments, after receivingthe requested data, the client application invokes a filtering operationto reduce the set of points, representing the value of a watchedparameter, plotted over a time period of interest on a graphicaldisplay. An exemplary set of filtering operations supported by theclient application are enumerated in FIG. 3 described herein below.

Turning to FIG. 3, an exemplary set of advanced data filtering/displaymodes, are supported by the client application on node 112 a. Theadvanced data filtering/display modes are facilitated by the set ofadvanced data retrieval operations 204 enumerated in FIG. 3. The set offilters are capable of operating on rows of data (grouped as cyclicbuckets) associated with a single, specific tag, or alternatively a setof specified tags. Furthermore, in the illustrative embodiment each ofthe filtering operations is implemented as a distinct object class fromwhich instances are created and started either at start-up, oralternatively, upon the client receiving a particular type of dataretrieval/presentation request.

In an exemplary embodiment, the filtering operations support options fortailoring data retrieval and processing tasks performed by the operationin response to a request. Options specified in a request invoking aparticular filtering operation include, for example, an interpolationmethod, a tirnestamp rule, and a data quality rule. Each of these threeoptions is described herein below.

With regard to the interpolation method option, wherever an estimatedvalue is to be returned for a particular specified time, the returnedvalue is potentially determined in any of a variety of ways. In anillustrative example, the filtering operations support stair-step andlinear interpolation. In the stair-step method, the operation returnsthe last known point, or a NULL if no valid point can be found, alongwith a cycle time with which the returned stair-step value isassociated. Turning to the example illustrated in FIG. 4 a, where theclient application operation receives a request for a “stair-step” valuefor a cycle having a boundary at time T_(c), and the most recent pointstored for the tag is P₁, the operation extends the last stored valueassigned at P₁ and returns the value V₁ at time T_(c).

Alternatively, linear interpolation is performed on two points to renderan estimated value for a specified time. Turning to the exampleillustrated in FIG. 4 b, where the client application receives a requestfor a linearly interpolated value for a cycle boundary at time T_(c),and the most recently stored point for the tag is P₁, and the firstpoint stored beyond T_(c) is P₂, the client linearly interpolatesbetween points P₁, and P₂. It is possible that one of the points willhave a NULL value. If either of the points is NULL value, then P₁ isreturned at time T_(c). If both points are non-NULL, then the valueV_(c) is returned as the value where the line through both pointsintersects with the cycle boundary, and the value V_(c) at time T_(c) isreturned to the client. Expressed in a formula V_(c) is calculated as:

V _(c) =V ₁+((V _(2 −V) ₁)*((T _(c) −T ₁)/(T ₂ −T ₁)))

for (T₂−T₁) ≠0.

In an exemplary embodiment, whether the stair-step method or linearinterpolation is used, if not overridden, is specified by a setting on arequested tag (for which data values are to be displayed). If thesetting is ‘system default’, then the system default is used for thetag. A client can override a specified system default for a particularquery and designate stair-step or linear interpolation for all tagsregardless of how each individual tag has been configured.

The “data quality” rule option on filtering operation request controlswhether points with certain characteristics are explicitly excluded fromconsideration by the algorithms of the filtering operations. By way ofexample, a request optionally specifies a data quality rule, which ishanded over to a specified filtering operation. A request optionallyspecifies a quality rule (e.g., reject data that does not meet aparticular quality standard in a predetermined scale). If no qualityrule option is specified in a request, then a default rule (e.g., noexclusions of points) is applied. In an exemplary embodiment, therequest specifies a quality rule requiring the responding filteringoperation to discard/filter retrieved points having doubtfulquality—applying an OLE for process control (OPC) standard. Theresponding operation, on a per tag basis, tracks the percentage ofpoints considered as having good quality by an algorithm out of allpotential points subject to a request, and the tracked percentage isreturned.

The time stamp rule option applied to a request to display data valuesfor an identified parameter/tag controls whether cyclic results are timestamped with a time marking the beginning of a cycle or the end of thecycle. In an illustrative example, a requestor optionally specifies atime stamp rule, and the time stamp is handed over to the operation.Otherwise, if no parameter is specified, then a default is applied tothe filtering operation.

Turning to the set of operations listed in FIG. 3, a best fit filteringoperation 250, used most appropriately for analog signals/values,calculates values to be provided to a point plotting process of theclient application over a period of time by dividing a period ofinterest into a set of sub-periods, and for each sub-period, applies afiltering rule to render a set of value representing the set of valuesprovided during the sub-period. The best fit filtering operation 250uses cyclic buckets, but it is not a true cyclic operation. Apart froman initial value for a cycle or sub-period, the best fit operation 250only returns actual delta points (i.e., where a parameter has changedvalue). The best fit operation 250 receives previously tabled data. Thebest fit filtering operation 250 applies the best fit algorithm(described below) to the received values in view of a specifiedresolution (sub-period duration). For best fit and other filteringoperations, the user can specify the resolution indirectly by specifyinga cycle count. The returned data values typically number more than oneper cycle. An option available for the best fit data filtering operation250 allows overriding the interpolation type for the calculation ofinitial values. The best fit filtering operation 250 applies the bestfit algorithm to all points found in any given cycle.

In an exemplary embodiment, up to five delta points are generated withineach cycle (displayed sub-period) for each tag: the first value, thelast value, the min value, the max value and the first occurrence of anyexisting exceptions. If one point fulfills multiple designations, thenthe data point is returned only once. In a cycle where a tag has nopoints, nothing will be returned. The best fit operation 250 is, by wayof example, applied to analog tags. All points are placed inchronological order for display, and if multiple data points are to beplotted for a particular time stamp, then those points will be returnedin the order in which the respective tags were listed in a query.

FIG. 5 shows an illustrative example of selecting points based upon abest fit filtering operation. In the example the best fit filteringoperation 250 commences with a start time of T_(C0) and an end time ofT_(C2). The resolution of the request is set such that data is returnedfor two complete cycles starting at T_(C0) and T_(C1) and an incompletecycle starting at T_(C2). For the queried tag we again fmd a total oftwelve points throughout the cycles represented by the dots marked P₁through P₁₂. Of these points eleven represent normal analog values, andone, P₇, represents a NULL due to an I/O server disconnect, which causesa gap in the data between P₇ and P₈. Two points, P₁ and P₁₂, are notconsidered at all. P₁ is not considered because P₂ is located exactly atthe start time and there is no need to interpolate. P₁₂ is notconsidered because it is outside of the queried time frame. All otherpoints are considered. However, for the reasons provided below, onlydata points 2, 4, 6, 7, 8, 9 and 11 are returned.

With continued reference to FIG. 5, four points are returned from thefirst cycle. P₂ is returned as the initial value of the query as well asthe first value in the cycle. P₄ is returned as the minimum value in thecycle. P₆ returned as the maximum value and the last value in the cycle.P₇ is returned as the first occurring—and in this case theonly—exception in the cycle. In the second cycle three points arereturned. P₈ is returned as the first value in the cycle. P₉ is returnedas the maximum value in the cycle. P₁₁ is returned as both the minimumvalue and the last value in the cycle. As no exception occurs in thecycle, no point will be returned for this aspect of the best fitoperation 350 for the second cycle. No points are returned for theincomplete third cycle starting at the query end time because the tag(associated with the displayed points) does not have a point exactly atthat time.

Returning to the set of operations listed in FIG. 3, a swinging doorfiltering operation 260, used most appropriately for analogsignals/values, calculates values to be provided to a point plottingprocess of the client application over a period of time by applying acombination of a value, rate and time deadband to an input stream. Thevalue deadband is applied first and eliminates low-level noise. Then therate deadband compares a slope between the last two points actuallyplotted with the slope between the last point plotted and the currentpoint of interest. If the slope is within the deadband, then the currentpoint is filtered out. The time deadband overrides values otherwisefiltered from the input stream and ensures that at least one point isplotted for a period specified by the time deadband. The first and lastpoints are always included. An exemplary swinging door filteringoperation/method is provided in FIGS. 6-9.

As noted above, the swinging door filtering operation 260 applies aconfigurable value/rate of change deadband compression operation,including a time period override. The swinging door filtering operation260 addresses a need to draw (plot on a graphical display) compresseddata in a manner such that the data streams provided to a data plottingcomponent of a client application reasonably reflect the signalinformation originally received by the client application from thehistorian 100. The filtering/corripression operation determines whetherto store/plot or discard a newly received value (data point) for aparticular tag where a value associated with the received data point hasnot changed sufficiently from a previous stored/plotted value for thetag. In an exemplary embodiment, a configuration interface associatedwith the swinging door filtering operation 260 allows an administratorto determine, for each data stream to be plotted on a graphical display:(1) whether value deadband compression is enabled (and the magnitude ofthe value deadband); (2) the magnitude of the rate of change deadband;and (3) whether time period overrides are enabled (and the magnitude ofthe time periods). The compression stages/steps are illustrativelydepicted in a flow diagram FIG. 6 described herein below.

FIG. 6 summarizes a set of steps describing the general operation of atime-series data compression operation that abstracts/reduces, prior toplotting on a graphical display of a client application, the content ofreceived data streams corresponding to a set of tracked process controlsystem information points. The abstracted data is thereafter plotted ona graphical display associated with the application client. It is notedthat the present invention is not to be limited by the disclosedspecific steps and their order of execution. As those skilled in the artwill appreciate from the disclosure contained herein, the tests (e.g.,rate change deadband, value change deadband, forced store periodoverride, etc.), the points used to carry out the tests, and theresulting actions can be modified in accordance with alternativeembodiments of compression operations falling within the scope of theinvention. For example, the choice of data points used to calculate arate change and a change in data point value, for purposes of applyingthe rate and value deadband tests, differs in alternative embodiments.Furthermore, the order in which the deadband and time-period based testsare performed differ in various embodiments.

The data compression decision steps described herein below rely upon thefollowing three points: a last drawn/plotted data point, a held overdata point, and a received data point. The last data point designated tobe drawn/plotted corresponds to the most recent (by timestamp) datapoint committed to the set of data points for a tag for plotting on theclient application's graphical display. The “held over data point”corresponds, by way of example, to the last received data point. The“received data point” corresponds to the data point received by theswinging door filtering operation 260 that resulted in the commencementof the steps set forth in FIG. 6.

The compression operation summarized in FIG. 6 applies two deadbands.First, an optional value deadband ensures that two compared values aresufficiently different. Second, a slope (rate) change deadbanddetermines whether a slope has changed sufficiently between two segmentsdefined by at least three distinct received points to justifystoring/plotting an intemiediate one of the three points. While knowncompression algorithms (described above in the discussion of the priorart) apply tests to either accept (for drawing/plotting) or discard amost recently received data point, it is noted that the compressionmethod described below holds over the most recently received data pointuntil a next data point has been received. Only after a next data pointis received do the compression decision steps summarized in FIG. 6determine whether to accept (for drawing/plotting) or discard the “heldover” data point.

It is noted that a first data point (e.g., the first ever received orfirst after a previous disconnect), in a stream of data points for aparticular tagged process variable, is automatically stored (forplotting) as an initial reference point. The flowchart depicted in FIG.6 assumes that this value has been stored and the steps address thesubsequently received points. Thus for all points received thereafter,the data point stream compression procedure including the steps depictedin FIG. 6 are commenced in response to the swinging door filteringoperation 260 receiving a new data point specifying a value andtimestamp for a particular tagged variable associated with thestatus/operation of a process control and manufacturing informationsystem.

Thereafter, during step 300, the swinging door filtering operation 260determines whether the held over data point has been specified. If noheld over data point presently exists, then control passes from step 300to step 302. At step 302 the received data point is stored as the heldover data point that will be used when a next data point is received. Ifthe held over data point exists, then control passes to step 303.

In an exemplary embodiment, the filtering operation 260 considers dataquality in addition to the value aspect of the held over data point.Therefore, in the illustrative embodiment, at step 303 the filteringoperation 260 determines whether the quality assigned the held over datapoint differs from the quality assigned to a last data point designatedto be plotted. If the data quality has indeed changed, then controlpasses to step 312 (described further herein below) wherein the heldover data point is designated for plotting on the client application'sgraphical interface. Otherwise, if the data point quality has notchanged, then control passes to step 304.

At step 304 swinging door filtering operation 260 determines whether avalue deadband compression function is enabled. The value deadbandcompression function is driven by a configurable offset magnitude thatidentifies neighboring points having sufficiently the same magnitude towarrant discarding at least one of the data points (e.g., a subsequentlyreceived one of two data points) in a stream of data points for aprocess variable. If the value deadband compression function is enabled,then control passes to step 306. At step 306, the held over point valueis compared to the last accepted data point for plotting. The mostrecently received data point value is not used to perform either step306 or step 308. Next, at step 308 if the magnitude of the differencebetween the held over data point value and the last plotted data pointvalue is within a deadband offset value, then the held over data pointcan potentially be discarded (without storing/plotting the value) sinceits value is not sufficiently different from the last data pointdesignated for plotting. Therefore, if the difference is within thevalue deadband, then control passes from step 308 to step 310.

An exemplary embodiment supports specifying a deadband override periodthat ensures at least one previously held over point value isaccepted/designated for plotting within the specified deadband overrideperiod commencing after a last accepted data point. At step 310, theswinging door filtering operation 260 performs a time period-baseddeadband override test. The override test carried out during step 310ensures that excessively long periods of time do not pass betweenplotted points. To ensure that such goals are met, prior to discarding aheld over point because it fell within a deadband, at step 310 theswinging door filtering operation 260 determines the elapsed timebetween the last data point designated for plotting and the currentreceived data point. If the elapsed time exceeds a specified overridetime span, then control passes to step 312. At step 312 the swingingdoor filtering operation associated with the client applicationdesignates the held over data point for plotting on the graphicaldisplay of the client application. Control then passes to step 302wherein the received data point is stored as the held over data point(in preparation for processing a next received data point). If theelapsed time does not exceed the override time period, then controlpasses from step 310 to step 302.

It is noted that an illustrative embodiment allows the deadband overrideto be selectively disabled/enabled. If the deadband override isdisabled, then all points that fall within specified value/ratedeadbands are discarded upon timely receipt of a next data point (whichstarts the deadband test sequence).

Turning briefly to FIG. 7, the effect of the override operation of steps310 and 312 is graphically depicted. After data point 10 is received(and data point 9 is presently the held over data point), during step310 the swinging door filtering operation 260 determines the elapsedtime since the last accepted data point (data point 2) exceeds thespecified deadband override period. The held over data point 9 istherefore accepted for plotting regardless of whether it falls outsideeither of the value and rate deadbands. A “deadband-overridden” point(e.g., data point 9) is treated no differently than any other acceptedpoint. In the example in FIG. 7, once point 9 is designated for plottingand point 10 becomes the held over point, subsequent rate calculationsuse the slope between points 9 and 10 as the baseline for subsequentdata point filtering decisions. The deadband override period can haveany value, and is not related to a real-time window period (describedherein below with reference to FIGS. 8 and 9).

Returning to step 308 if the difference between the last accepted datapoint's value and the held over data point value is not within thespecified deadband, then control passes to step 314 wherein a rate ofchange deadband test commences. In the rate of change deadband test, theslopes of two data segments are compared. In an exemplary embodiment thetwo data segments are defined by at least: the last accepted data point,the held over data point, and the received data point, are compared. Ifthe slopes differ insubstantially, then the held over point—which islocated in a time sequence between the last stored value and thereceived value—can potentially be discarded. If the value deadband testis not enabled, then control passes from step 304 to 314.

Steps 314 and 316 embody an exemplary slope change deadband test (one ofmany potential alternative tests) for determining whether to accept(designate for plotting) or discard a held over point. During steps 314and 316 the swinging door filtering operation 260 determines whether theslopes of the two compared segments are sufficiently different towarrant accepting the held over data point. At step 314, the filteringoperation 260 determines a difference between a first segment defmed bythe last stored data point and a first subsequently received/held overdata point, and a second segment defmed by the current held over datapoint and the current received data point.

In the illustrative embodiment the slope of the first segment is keptand reused until a new last accepted data point is established. Thus,turning briefly to the example set forth in FIG. 8, when data point 1 isaccepted for plotting, the slope between point 1 and point 2 is saved asthe “previously stored slope” until point 6 is received. A comparisonbetween the slopes of segment 1-2 and segment 5-6 results in acceptingdata point 5, and the slope between data points 5 and 6 is saved as the“previously stored slope” until a next data point (i.e., data point 10)is accepted/designated for plotting.

In an alternative embodiment the first segment (utilized during step314) is updated each time a new held over point is established. Thisalternative, while potentially consuming more processing cycles (tocalculate an updated first segment), potentially provides a better firstsegment slope for comparing to the second segment slope—which is definedby the held over and received data point values.

There are many ways to specify a slope/rate of change deadband inaccordance with alternative embodiments. Returning to FIG. 8 forpurposes of describing the application of a rate deadband test, asequence of received data points is depicted. In the case depicted inFIG. 8, it is assumed that value deadband compression has been disabled.Data point 0 has been stored on disk. Data point 1 is the held over datapoint. Thereafter, the swinging door filtering operation 260 receivesdata point 2 and calculates a change in slope. In the exemplaryembodiment, the change in slope is calculated as a percentage of apreviously stored slope. In particular, when data point 2 is received,at step 310 the storage engine calculates the change in slope asfollows:

Slope0_(—)1=(Value1−Value0)/(Time1−Time0)

Slope1_(—)2=(Value2−Value1)/(Time2−Time1)

*Test for Slope0_1=0

If Slope0_(—)1=0 then Percent>Rate Deadband elseSlope_Change_Percent=|100*(|Slope1_(—)2−Slope0_(—)1|/Slope0_(—)1)|

The above equation for calculating a “slope change percent” presents apotential “divide by zero” error (if slope0_1 equals zero). Aconditional is therefore interposed between calculating the slope of thedenominator and calculating the slope change percent. If the denominatoris zero, then the slope change percent calculation is by-passed (and theslope change is considered sufficient for purposes of the deadbandapplied during step 316). In an alternative embodiment, the slope changeis calculated as a difference (e.g., slope 1−slope 2) rather than apercentage. In yet another, hybrid value/rate deadband embodiment therate change test is performed by extending/extrapolating a line definedby the last stored data point and held over data point to a timecorresponding to the received data point. If a value for a point on theline corresponding to the timestamp of the received data point issufficiently close to the value of the received data point, then theheld over data point is not stored (i.e., the value/rate deadband is notexceeded).

After determining the slope change, control passes from step 314 to step316 wherein, a rate of change criterion is applied to determine whetherthe slope change determined during step 314 is within aspecified/configurable rate change deadband. By way of example, if theSlope_Change_Percent>Rate_Deadband_Percent (e.g., 10 percent), then theslope has changed sufficiently, and control passes to step 312 whereinthe held over data point is accepted/designated for plotting/display bythe client application user interface. Alternatively, instead of aspecified percent value, during step 316 the test for determiningwhether the slope has changed sufficiently comprises comparing a slopedifference to a specified slope difference deadband value. In the otherproposed hybrid value/rate comparison alternative, where a line segmentis extended for the purpose of making a comparison, the change isexpressed in actual measurement units

On the other hand, if the swinging door filtering operation 260concludes, at step 316 that the slope change determined during step 314is not sufficiently large (i.e., the change is within the specifieddeadband), then control passes from step 316 to step 310 (describedabove) where a time override is applied.

With further reference to FIG. 8, it is noted that with regard to thesubsequently received points after point 2, the slope (that is assumednot to be zero for purposes of this example/discussion) has not changedbetween points 2 through 5, and therefore as points 2 through 5 arereceived and processed, none of these points are designated for plottingas a result of the test performed during step 316. It is noted that ifthe slope was indeed zero, then each of the intervening points wouldhave been stored due to the divide by zero condition. However, whenpoint 5 has been designated as the held over point and data point 6 isreceived, the rate deadband criterion is satisfied (slope change betweenpoints 1-2 and points 5-6 is greater than the specified rate deadband),and point 5 is designated for plotting. Point 6 is subsequentlydiscarded because the slopes between the two line segments defined bydata points 5, 6 and 7 are not substantially different. The next pointwhere the slope changes significantly is at the segment defined bypoints 10 and 11. After point 11 has been received, during step 314 theslopes of the segment 5/6 and segment 10/11 are used to determine theslope change. Thereafter, at step 316 the swinging door filteringoperation 260 determines that the slope differences indeed fall outsidethe Tate deadband. Control thereafter passes to step 312 wherein theheld over data point 10 is designated for plotting. Control then passesto step 302 wherein the received data point 11 is stored as the new heldover data point.

It is noted that the disclosed set of data compression steps can be, andindeed are, supplemented by a real-time period timer-based forcedstorage procedure. Such procedure, described herein below with referenceto FIGS. 8 and 9, causes a held over data point to be designated forplotting on the client application's associated graphical display eventhough a subsequent data point has not yet been received. Such forcedstorage period is preferably set at a value that is less than a timeperiod used to designate a received data point as “real-time”. Anexample of such a period is 30 seconds.

Turning to FIG. 9, a flowchart summarizes a set of steps for applying areal-time window forced display requirement to a stream of received datapoints for a particular tagged 5. variable. In contrast to the deadbandforced display period, the real-time window begins at the time specifiedon a timestamp for a held over data point. Upon expiration of the timeperiod at step 600, control passes to step 602. At step 602 the swingingdoor filtering operation 260 designates the previously received/heldover data point for plotting/display on the graphical interface of theclient application. Next, at step 604, the held over data point isspecified as Null/Undefined. Thus, when a next data point is received,the swinging door filtering operation 260, applying the steps summarizedin FIG. 6, will determine that there is no presently specified held overpoint and therefore by-pass the deadband tests. The received point ismerely stored as the new held over data point.

Referring to FIG. 8, for purposes of illustrating the effect of the“real-time” window timer, data point 13 illustrates the effect of thereal-time window setting. Under normal circumstances, data point 12would not qualify for being plotted. If, however, the elapsed timebetween the timestamp specified for received data point 12 and datapoint 13 exceeds the time period window in which the data point 12 isstorable as a real-time point (e.g., the specified real-time window is30 seconds and the elapsed time between points 12 and 13 is greater than30 seconds), data point 12 is plotted anyway. Furthermore, a system tagcounting “extra” points plotted as a result of an insufficient real-timewindow is incremented. In other words, if while waiting for data point13 to arrive, the timestamp_(.)of data point 12 becomes so old that itreaches the limit of the real-time window, then data point 12 isdesignated for plotting/display without consideration of the tests setforth in FIG. 6.

Returning to FIG. 3, a value/time filtering operation 270 is mostappropriate for discrete measurements represented as integer values. Thevalue/time filtering operation 270 includes two distinct filters. Afirst filter discards a string of time-series values for a tag/parameterthat fall within a deadband centered, for example, on a most recentlydesignated/plotted value for the tag/parameter. A second filter discardsa string of time-series values for a tag/parameter having a time-stampfalling within a designated period. By way of example, after a value isstored for a tag/pararneter, a hold period commences where all valuesfor the tag/parameter having time stamps falling within the hold periodare not plotted on the graphical display.

Turning to FIG. 10, a set of steps summarize processing a received datapoint by the value/time filtering operation 270. As each point isreceived for processing by the filtering operation during step 1000 avalue-based filter is applied, and an initial comparison is performedbetween the received data point value and a last accepted data pointvalue. If the magnitude of the difference less than a specified valuedefining the deadband, then control passes to step 1005 and the datapoint is rejected for purposes of plotting on the graphical displayassociated with the client application. If, however, the differenceindicates that the value of the received data point is outside thedeadband, then control passes to step 1010.

During step 1010, a time filter is applied to the timestamp associatedwith the received data point. If the timestamp falls within a holdperiod defined by the timestamp and a specified duration (e.g., onesecond) where data points are discarded regardless of whether they falloutside the deadband. At step 1010, if the timestamp difference betweenthe received data point and a most recently received data point does notexceed the hold period duration (e.g., 1 second), then control passes tostep 1005. As an alternative to the above-described hold period testduring step 1010, a hold period criterion can merely specify that duringany given fixed time period only a limited number of data point values(e.g., one) will be plotted. In this alternative embodiment, thetimestamp of a last accepted data point value is not needed since thebeginning of the periods are determined by an independent timer thatmeasures the fixed time periods. If the hold period test is met duringstep 1010, then control passes to step 1015. During step 1015 thereceived data point is designated for plotting on the clientapplication's graphical display.

Having described an exemplary value/time filtering operation 270 withreference to FIG. 10, it is noted that a variety of alternativevalue/time filtering operations are contemplated in alternativeembodiments. In addition to the above-mentioned variation on the “holdperiod” test, the value test performed during step 1000 can take on avariety of forms. Furthermore, while the exemplary value/time filter isperformed on discrete data values, in alternative embodiments, thevalue/time filter operation is carried out on analog values.Furthermore, the order of performing the value and time filtering testsis switched in alternative embodiments such that step 1010 is performedprior to deadband testing in accordance with step 1000.

It is noted that the data point plot filtering operations performed bythe client application, and identified by way of examples specified inFIG. 3, are used to determine whether a received data point isplotted/drawn on a graphical display associated with the clientapplication. Thus, in embodiments of the client application time-stampeddata point values rejected by any of the above-described filters arestill used to perform other analytical computations supported by theclient application. In other embodiments therejected data points are notused subsequently for any purpose by the client application.

Turning to FIG. 11, a set of stages are summarized for an exemplaryclient application's processing of a series of time-stamped data valuesfor a parameter/tagged variable. Initially, during stage 1100, acandidate set of values are received by the client application forplotting on a graphical display. The input set of data values ispotentially pre-filtered by other processes—such as ones associated witha process database from which the data values have been received. Inother cases, the values have not previously been filtered. Next, duringstage 1110, the client application invokes a filtering operation topotentially reduce the number of data values that are actually plottedon a graphical display with which the client application is associated.It is noted that the filtering operations can be implemented in avariety of ways including, for example, integrated components of theclient application. In other embodiments, the filtering stage 1110invokes an external application/component to carry out the actualfiltering. After obtaining the designated set of data point values to beplotted by the client application, during stage 1120 client applicationplots the designated set of points on its associated graphical display.

An example of such a display for the client application is provided inFIG. 12. In the example, a graphical interface for the clientapplication comprises a line graph display 1200 that plots a set ofpoints associated with a process. Rather than plot every single point onthe line, filtered data values are plotted and thereafter connected byan appropriately colored line to form a line graph (e.g., line graph1202).

It is noted that in exemplary embodiments the set of filteringoperations supported by the client application is extensible. Theextensible nature of the client application's data filtering set ensuresthat as additional needs are identified, new filtering operations aredeveloped and incorporated within the client application's operations. Adesired one of the supported filtering operations is specified by aconfigurable option for a particular trending view.

Particular ones of the supported operations are invoked in a variety ofways. In an illustrative example, the operations are invoked as OLEextensions to a standard/base interface.

In an alternative example wherein one or more of the received data pointfiltering operations are implemented by object instances (e.g., COM/DCOMobjects), a client application invokes the particular filteringoperation of interest through a call to an object instance fordesignating particular ones of a set of provided data points to beplotted/drawn on the client application's graphical display.

In view of the many possible embodiments to which the principles of thisinvention may be applied, it should be recognized that the embodimentsdescribed herein with respect to the drawing figures, as well as thedescribed alternatives, are meant to be illustrative only and should notbe taken as limiting the scope of the invention. The functionalcomponents disclosed herein can be incorporated into a variety ofprogrammed computer systems as computer-executable instructions(provided on a computer-readable medium) in the form of software,firmware, and/or hardware. Furthermore, the illustrative steps may bemodified, supplemented and/or reordered without deviating from theinvention. Therefore, the invention as described herein contemplates allsuch embodiments as may come within the scope of the following claimsand equivalents thereof.

1. A process control and manufacturing information database clientapplication including a graphical display interface for plotting andpresenting received time-series data, the client application comprising:a data acquisition interface for obtaining a set of timestampedtime-series data values for an observed parameter from a process controland manufacturing information database; a time-series data filterincluding at least one filtering operation applied to the set oftimestamped time-series data values to render a filtered data set forplotting on the graphical display interface; and a display function forrendering the filtered data set as a series of plotted points on atime-line graph.
 2. The client application of claim 1 wherein the atleast one filtering operation comprises a filter that selects a set ofrepresentative data points, of a grouped set of time-stamped time-seriesdata values associated with a designated time period, according to avalue-based selection criterion.
 3. The client application of claim 2wherein the value-based selection criterion includes designating for thefiltered data set, from the grouped set, at least: a data point having alargest value, and a data point having a smallest value.
 4. The clientapplication of claim 3 wherein the value-based selection criterionincludes a first data point after an exception.
 5. The clientapplication of claim 3 wherein the value-based selection criterionincludes designating for the filtered data set, from the grouped set, atleast: a first data point within the designated time period, and a lastdata point within the designated time period.
 6. The client applicationof claim 5 wherein the value-based selection criterion includes a firstdata point after an exception.
 7. The client application of claim 1wherein the at least one filtering operation comprises a filtercomprising: a compression test sequence applied, upon receiving a nexttime-series data point, to at least the received next time-series datapoint, a held over data point and a last data point designated forplotting; and a time override that forces designating a candidate datapoint for plotting without regard to whether the candidate point wouldbe stored as a result of applying the compression test sequence, uponreceiving the next time-series data point.
 8. The client application ofclaim 7 wherein the candidate data point is the held over data point. 9.The client application of claim 8 wherein the time override comprises anoperation that determines an elapsed time between the last data pointdesignated for plotting and the next time-series data point anddesignates the held over data point for plotting if the elapsed timeexceeds a specified override time period.
 10. The client application ofclaim 8 wherein the time override further comprises a real-time windowtimer that measures an elapsed period after the time stamp of the heldover point and designates the held over data point for plotting inresponse to a specified period, measured by the real-time window timer,expiring.
 11. The client application of claim 7 wherein the compressiontest sequence comprises a value deadband test that is applied to theheld over data point and the last data point designated for plotting.12. The client application of claim 7 wherein the compression testsequence comprises a rate deadband test that is applied to at least thelast data point designated for plotting, the held over data point, andthe next time-series data point.
 13. The client application of claim 12wherein the rate deadband test comprises determining a change in slopebetween a first line segment and a second line segment, wherein thefirst line segment includes at least the last data point designated forplotting, and the second line segment includes the next time-series datapoint and the held over data point.
 14. The client application of claim13 wherein the first line segment further comprises the held over datapoint.
 15. The client application of claim 7 further comprising aquality change test wherein the held over data point is designated forplotting if a quality assigned to the held over data point differs fromthe quality assigned to the last data point designated for plotting. 16.The client application of claim 1 wherein the at least one filteringoperation comprises a discrete filter including at least a deadbandstage.
 17. The client application of claim 16 wherein the at least onefiltering operation comprises a discrete filter including at least atime period-based data point filtering stage.
 18. The client applicationof claim 1 wherein the at least one filtering operation comprises adiscrete filter including at least a time period-based data pointfiltering stage.
 19. The client application of claim 1 wherein a set offiltering operations making up the time-series data filter isextensible.
 20. A method for displaying, by a process control andmanufacturing information database client application, receivedtime-series data, the method comprising the steps of: obtaining, via aclient data acquisition interface, a set of timestamped time-series datavalues for an observed parameter from a process control andmanufacturing information database; rendering from the set oftimestamped time-series data values, by a time-series data filterincluding at least one filtering operation invoked by the clientapplication, a filtered data set for plotting on the graphical displayinterface; and rendering, by a display function of the clientapplication, the filtered data set as a series of plotted points on atime-line graph. 21-29. (canceled)